AGB Multi-play Boot Library Manual
2001.2/3 Version

  **What is Multi-play Boot?
  **Multi-play Boot
    *Multi-play Boot Library
    *Different uses of slave recognition
    *When the Game Pak is inserted in slaves
    *Slave with Game Pak inserted accessing a Game Pak
    *Startup Game Pak from downloaded program
    *Changes for programs to be downloaded (Transfer speed)
    *Changes for programs to be downloaded (Execution speed)
    *Transfer error
  **Muli-play Boot naming convention
  ** Revision History


**What is Multi-play Boot?
--------------------------

This is a feature that enables AGB not inserted with a Game Pak to boot and 
execute the program which is downloaded from external source.

The downloaded buffer is "CPU External Work" which is installed in AGB.  
It can download the maximum of 2M bits (256K bytes) of programs.

The program is downloaded from AGB inserted with a Game Pak by connecting AGB 
communication cable to 6-pin serial board.

When multi-play is played, it allows the players who do not have the Game Pak 
to participate in the game play.

However, when compared with the Game Pak, the capacity used to keep program and 
character data is small.  This causes lower quality and allows less time to 
download game data.


**Multi-play Boot
-----------------

One master and maximum of three slaves are connected by the AGB multi-play 
communication cable.

Game Pak is inserted in the master and slaves are either without Game Pak or 
inserted with the same Game Pak as the master.

The master automatically recognizes the connected slaves by the multi-play boot
library. By starting instruction, which is done with the button control on the 
master, download the program to the slaves without executing the Game Pak.  

For the slaves inserted with the same Game Pak as with the master, 
conduct download wait control to set in the download mode.

If the slave is not set in the download mode, the slaves inserted with Game Pak 
boot with the Game Pak program. This prevents them from downloading the program 
from the master.

By the value returned from boot library, the master determines whether or not the 
slaves without Game Paks or the slaves with Game Paks (which are in the download
mode) have successfully booted by downloading data from the master.

When all the slaves do not end communication normally, i.e., when even one of the
slaves is determined to have communication error, all the slaves fail in booting.

The Multi-play communication game can be executed among the maximum of 4 AGB.


*Multi-play Boot Library
------------------------

Link multi-play boot library and the program which you want to download to slaves
to the program on master. The recognition process "MultiBoot.c" in Multi-play Boot
is a process example. You may change the process in the way you like.

The program on slave can be created as the program in ROM. 
Differences are as follows:

  1. It is necessary to initialize the mode of the serial device at the time of 
     boot prior to using it because it depends on the booted mode. 
  2. Use rt0_multi_boot.s, instead of crt0.s.
  3. Set the start address of text section as 0x02000000. (It is 0x08000000 with ROM)
  4. When starting up, do not do a zero clear for the CPU external working RAM 
     where the program is loaded.
     (The content of the CPU external working RAM where the program is not 
      loaded is undetermined.)

The bss section starts at 0x03000000 in the enclosed sample program.  
If any, it is acceptable to use the extra space in CPU external work RAM area
that is secured in the text section. (For example, from 0x02030000)

Set the program on the slave as binary and link to the program on the master.

When the master calls the boot library, secure multi-play boot parameter structure
in addition to 

  #include "MultiBoot.h".

The example would be 

  MultiBootParam multiboot_status;

First you need to set up the stucture members masterp and server_type (slave 
recognition method).
  multiboot_status.masterp = demo_bin_start;
  multiboot_status.server_type = MULTIBOOT_SERVER_TYPE_NORMAL;
  (or                             MULTIBOOT_SERVER_TYPE_QUICK)

Afterwards, call an initializing function MultiBootInit().
Make sure you first set up the members masterp and server_type as in the example above. 

Once initialized, call every frame MultiBootMain().
If MultiBootMain() returns something other than 0, a communication error occurred. 
Check the cable connection and status of the slave.

However, even if the cable is not connected or the connection is bad, 
MultiBootMain() may return a 0.
(For the multi-play communication itself, even if the cable is not connected, 
no error flag will occur). If the structure member, client_bit, is 0, no slaves 
are recognized.

When the structure member, probe_count, is 0 and client_bit is not 0, a slave 
corresponding to the bits for client_bit is being recognized.
Call the function MultiBootStartMaster() and start download to slave.

Continue to call MultiBootMain() even after MultiBootStartMaster().
Normally, system call MultiBoot() is called within several calls of MultiBootMain(),
and the main process of downloading is executed.

When the function MultiBootCheckComplete() returns a value other than 0, 
download ended success. All the slaves that have been recognized should be booted.

Basically, a download can be started automatically, however, the button control on 
the master is recommended when the multi-play boot does not recognize the 3 slaves 
(since it is not known how many more would be connected).


*Different uses of slave recognition
-------------------------------------

There are two types of methods for recognizing slaves, "Low speed recognition mode" 
and "High speed recognition mode". 

In Low speed recognition mode, with each call of MultiBootMain(), there is 
at most 2 bytes(one time) of serial communiction processing for recognition 
processing.(Excluding processing for data main unit transfer by MultiBoot() system call)
Therefore, in order to communicate all the data for recognition, it takes 
some time. 
But, the MultiBootMain() function recognition processing finishes in a short 
time.

In High speed recognition mode, all the data for recognition is communicated 
at once within the MultiBootMain() function.
Therefore, there may be times when the MultiBootMain() recognition processing 
does not end quickly. It may be a maximum of several dozen frames that 
processing does not return from this function.  
(If the communication status is normal, the standard recognition processing 
time is a maximum of 5 frames or less.)

With sound processing and display processing, if you are doing simultaneous 
processing of necessary processes during each frame, and slave recognition processin, 
use the Low speed recognition mode.

If no sounds are being produced, if the display processing is not necessarily 
being called every frame, and there are no problems you can use High speed recognition mode.

The recognition processing of MultiBootMain() uses no interrupts so nothing happens 
even if there is an interrupt.

If the programmer does sound or display processing with a timer interrupt, 
soundor display processing can be done in High speed recognigtion mode 
with an equivalent interval.

During MultiBoot() system call processing, internal interrupts are prohibited.

The sample program will run in either High or Low speed recognition mode.


*When the Game Pak is inserted in slaves
----------------------------------------

Not supported by TS2 or previous versions of the target board.

By pressing SELECT Button and START Button simultaneously when booting, the 
slave with Game Pak inserted cancels the boot from Game Pak and goes in the 
download wait status (download mode) to download data from the master.

Once it is in the download wait status, the master treats it same as the slaves 
without the Game Pak, and recognition and download process is done properly.

Before the download has started, you can cancel the download wait status by 
pressing A, B Buttons or Control Pad, and it boots program from Game Pak.


*Slave with Game Pak inserted accessing a Game Pak
--------------------------------------------------
From the program being run on the slave the Game Pak is inserted into, you can 
read/write the region in the Game Pak ROM internal registration area from the 
software title(0x080000A0) to 0x08000FFF, and the backup data region.

If there is no need, do not access the Game Pak.

This section explains the things to note when the slave accesses the Game Pak.
Make sure you first do a check of the initial code(0x080000AC) and fixed value 0x96(0x80000B2) for ROM internal registration area. If a Game Pak differing from the master is inserted display this on the screen and stop running the program. 
It is possible that the master and the slaves have Game Paks with the same game 
title and the company code, but with different versions. In order to avoid such
a situation, be sure to unify the format of backup data among all the versions.

When ROM area other than the registration area in ROM is referred, unify the 
contents among all the versions.

For example, when the master has an older version of the Game Pak and the slave
has a newer version, the slave accesses the backup data area and ROM area with 
the program downloaded from the master.

If the forms of backup data are not compatible, they could destroy data or 
cause problems.

Contact the NOA Developer Support (support@noa.com) if it is necessary to 
access a Game Pak that is different from the one inserted in the master 
(for example, different color versions of Pokemon).

*Startup Game Pak from downloaded program
----------------------------------------------

Using multi-play boot and multiple Game Paks together.
(Mix of slaves with Game Pak/No Game Pak)
First, go to download wait status (download mode) with the slaves the user 
has inserted Game Paks into by pressing START and SELECT at the same time. 
Carry out multi-play boot. 

With the download program, check the initial code (0x080000AC) and fixed 
value 0x96(0x080000B2) of the ROM internal registration area of the Game Pak.
*However, you cannot access ROM regions outside of area between the software 
title name (0x080000A0) and 0x08000FFF of the ROM internal registration area. 

Only when the assumed initial code and fixed value are 0x96 is the Game Pak 
started up.

Without changing the communication function setting flag of the general use 
communication register (REG_RCNT) when running the download program, by 
specifying to reset settings other than communication as shown below, the 
system call, SoftResetRom(), is called and the Game Pak program is run.

    SoftResetRom(RESET_ALL_FLAG ^ RESET_REG_SIO_FLAG);

With a normal run, the communication function setting flag for the general 
use communication register is in general use input/output mode.
With the Game Pak program if this flag is not in general use input/output 
mode, assume it was started up from the download program.

*Changes for the program to be downloaded (Transfer speed)
----------------------------------------------------------

It takes time to download.  The more slaves that are connected, the slower the 
transfer speed.  When 3 slaves are connected, the transfer speed is about 2.5K
bytes/second.

To reduce the download time, the enclosed sample program has downloaded 
"Expansion program and compressed data (original program + character)". Please 
see it as a reference.

After the boot has completed, it expands compressed data to the extra area in the 
CPU external work RAM (from 0x02010000) and executes the original program.

Rather than downloading all the programs and character data in the beginning, 
it is recommended that the download be executed in a manner that users do not 
feel like they have to wait too long until download completes.


*Changes for the program to be downloaded (Execution speed)
----------------------------------------------------------

The downloaded program is executed on the CPU external work RAM by default.  
The CPU prefetch function for the program code does not operate on RAM, and the
execution speed slows down since the CPU external work RAM is 2 wait access.

Execution speed improves when the interrupt process and frequently repeated loop 
are changed to be executed on the CPU internal work RAM. 


*Transfer Error
----------------------------------

Under the following conditions, the multi-play boot fails.

  1. DMA flag is turned on
     Stop DMA including direct sound.

  2. Transfer source data address and transfer size are incorrect
     For example, transfer source data address being 0x00000000 (System ROM) 
     causes an error.

**Muli-play Boot naming convention
======================================

The name "Multi-play boot" is for developers so in the game use a name or 
icon that is easier to understand by users.

***Revision History

==============================

  Changes in 10/25/00 Version
-----------------------------------------------

Please replace the system include file, AgbMultiBoot.h, with the most recent version.

Updated
MultiBoot.c, MultiBoot.h, main.c, and 
crt0_multi_boot.s


Created Low speed mode(same as before) and High speed mode for slave recognition processing.

Added handshake procedure for checking if slave has actually booted.
Refer to crt0_multi_boot.s.
If slave's recognition processing is in Low speed mode the handshake is low speed, 
and in High speed mode the handshake has high speed processing. 

Updated document.

  Changes in 10/25/00 Version  
----------------------------------

Updated the Multi play communication library. 


  Changes in 12/14/2000 Version
----------------------------------
 Correction of "Slave with Game Pak inserted accessing a Game Pak"
 Addition of section "Startup Game Pak from downloaded program"
 Addition of section "Muli-play Boot naming convention"

Changed access wait to Game Pak when sample program starts to 3-1.


  Changes in 2/3/2001 Version
----------------------------------

Addition of Game Pak insert check.

Enter an infinite loop when Game Pak is interrupted. 

Updated the multi-play communication library. 

Changed the communication interrupt to the highest priority. 

Improved the key read routine.

